Appliance development toolkit with universal editor

ABSTRACT

An appliance development toolkit is provided to enable creation of content to affect operation of a component in an appliance or to affect user interaction with an appliance, and includes appliance user domain data or source identification domain data, an editor to create instances of data elements related to functionality of an appliance or the editor derived in part from the domain data, an interactive user interface on which the editor is displayed for use by a developer, and a converter to generate content using the data elements created by the instance. The editor is configured at least in part by the domain data irrespective of the appliance so that the appliance development toolkit can be used for different appliances without recoding.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of PCT/US2009/046186 filed Jun. 3,2009, which claims priority from U.S. Application Ser. No. 61/058,440filed Jun. 3, 2008.

FIELD OF THE INVENTION

The invention relates to tools for editing software associated with theoperation of household appliances.

DESCRIPTION OF THE RELATED ART

Household appliances typically comprise one or more componentsresponsible for the electromechanical operations of the appliance. Forexample, an oven can include an appliance management component having aprinted circuit board (PCB) with memory, as well as a user-interfacecomponent, such as a control panel or keypad, for a user to issuecommands to the oven. As another example, a washing machine can includean appliance management component, a user-interface component, and amotor control component that controls a motor of the washing machine.

Typically, discrete circuits couple the internal components of anappliance, with each discrete circuit responsible for individualcommunication between related components. The circuits communicate witheach other over an internal network that traditionally is implemented byhard-wired ribbon cables or other connectors or harnesses between thecomponents. The hard-wired connectors form a closed system or networkthat is difficult or not possible to modify. For example, because theclosed network relies on hard-coded or hard-wired network solutions, itis not practical to couple additional external components or additionalinternal components to the appliance to expand the capability orfunction of the appliance. The closed network cannot easily be adaptedfor communication with the additional external/internal components andtherefore limits the potential of the appliance.

In some instances, service personnel can access the interior of anappliance and connect an external device to the internal network inorder to modify the operation of or otherwise interact with the internalcomponents of the appliance. However, scheduling appointments withservice personnel can be inconvenient, and accessing the interior of theappliance can require the use of specialized tools and can potentiallydamage the appliance in the process. In addition, due to the limitedpotential of the internal components, the user of the appliance isunable to thoroughly personalize the operation of the appliance in orderto tailor the appliance to his or her particular needs.

SUMMARY OF THE INVENTION

An appliance development toolkit according to the invention is providedto enable creation of content to affect operation of a component in anappliance or to affect user interaction with an appliance. The toolkitcomprises appliance user domain data or source identification domaindata, an editor to create instances of data elements related tofunctionality of an appliance or to functionality of the editor derivedin part from the appliance user domain data or the source identificationdomain data, an interactive user interface on which the editor isdisplayed for use by a developer, and a converter to generate contentusing the data elements created by the instance. The editor isconfigured at least in part by the appliance user domain data or thesource identification domain data irrespective of the appliance so thatthe appliance development toolkit can be used for different applianceswithout recoding.

BRIEF DESCRIPTION OF THE DRAWINGS

In the drawings:

FIG. 1 is a schematic diagram showing the environment of an appliancedevelopment toolkit according to the invention.

FIG. 2 is a schematic diagram showing elements of an appliancedevelopment toolkit according to the invention.

FIG. 3 is a schematic diagram showing relationships among elements ofthe system configurator in the appliance development toolkit of FIGS. 1and 2.

FIG. 4 is a diagram showing the functional relationship among some ofthe elements of FIG. 3.

FIG. 5 is a screen shot of an editor and a content viewer of anappliance development toolkit according to the invention.

FIG. 6A shows a first embodiment of a user interface as a result ofusing an appliance development toolkit according to the invention.

FIG. 6B shows a second embodiment of a user interface as a result ofusing an appliance development toolkit according to the invention.

FIG. 6C shows a third embodiment of a user interface as a result ofusing an appliance development toolkit according to the invention.

FIG. 7 is a screen shot of two editor windows in an appliancedevelopment toolkit according to the invention and a cycle structure foran appliance.

FIG. 8 is a schematic diagram showing the flow of information between anappliance and the system configurator in an appliance developmenttoolkit according to the invention.

FIG. 9 is a schematic diagram showing the relationships of the controlstructure of an appliance to the system configurator of FIG. 8.

FIG. 10 is a screen shot of an editor in an appliance developmenttoolkit according to the invention with a sequence model instance for afault tree being created.

FIG. 10A is a screen shot of an attribute editor in an appliancedevelopment toolkit according to the invention showing the creation of aportion of the instance of FIG. 10.

FIG. 11 is a screen shot of an editor in an appliance developmenttoolkit according to the invention with a sequence model instance for afault tree being created.

FIG. 11A is a screen shot of a viewer in an appliance developmenttoolkit according to the invention showing how the content resultingfrom the editor will appear.

FIG. 12 is a screen shot of the editor of FIGS. 10 and 11, and a screenshot of a graphical user interface in an appliance displaying a portionof the content from the editor.

FIG. 13A is a screen shot of the editor of FIGS. 10 and 11, and a screenshot of a graphical user interface in an appliance displaying anotherportion of the content from the editor in a query.

FIG. 13B is a screen shot of the editor of FIGS. 10 and 11, and a screenshot of a graphical user interface in an appliance displaying relatedportion of the content from the editor responsive to the query of FIG.13A.

FIG. 14 is a screen shot of a viewer in an appliance development toolkitaccording to the invention showing a flow chart of the content in FIGS.12-13B.

FIG. 15 illustrates an interaction between the content of FIGS. 12-13Band a user.

FIG. 16 is a screen shot of an editor in an appliance developmenttoolkit according to the invention with a message data payload modelinstance being created

FIG. 17 is a schematic diagram showing the use of the message datapayload model instance of FIG. 16 in an appliance.

FIG. 18 is a screen shot of a viewer in a target application showing themessage traffic of the message data payload model instance of FIG. 16

FIG. 19 is a screen shot of a model instance editor in an appliancedevelopment toolkit according to the invention showing a step in thecreation of a message data payload.

FIG. 20 is a screen shot of a model instance editor in an appliancedevelopment toolkit according to the invention showing another step inthe creation of a message data payload.

FIG. 21 is a screen shot of a model instance editor in an appliancedevelopment toolkit according to the invention showing another step inthe creation of a message data payload.

FIG. 22 is a screen shot of a model instance editor in an appliancedevelopment toolkit according to the invention showing another step inthe creation of a message data payload.

FIG. 23 is a screen shot of a model instance editor in an appliancedevelopment toolkit according to the invention showing another step inthe creation of a message data payload.

FIG. 24 is a schematic diagram showing a binding between appliance userdomain data and control system domain data created by an editor in anappliance development toolkit according to the invention.

FIG. 25 is a schematic diagram showing use of a constrained appliancedevelopment toolkit according to the invention.

FIG. 26 is a schematic diagram showing a constrained appliancedevelopment toolkit according to the invention.

FIG. 27 is a screen shot of a model instance editor in an appliancedevelopment toolkit according to the invention showing aspects of amessage data payload.

FIG. 28 is a schematic diagram showing elements of an appliancedevelopment toolkit according to the invention and an appliance thatuses content from the appliance development toolkit in creating themesand animations.

FIG. 29 is a schematic diagram showing multiple bindings created by anappliance development toolkit according to the invention for userinterface controls in an appliance.

FIG. 30 is a schematic diagram showing the message structure of forkingelements in an appliance development toolkit according to the invention.

FIG. 31 is a screen shot of a model instance editor in an appliancedevelopment toolkit according to the invention showing a step in thecreation of a message data payload with a forking element.

FIG. 32 is a screen shot of a model instance editor in an appliancedevelopment toolkit according to the invention showing another step inthe creation of a message data payload with a forking element.

FIG. 33 is a screen shot of a model instance editor in an appliancedevelopment toolkit according to the invention with a properties viewerand information about it.

FIG. 34 is a screen shot of a model instance editor in an appliancedevelopment toolkit according to the invention with information aboutit.

FIG. 35 is a screen shot of a model instance editor in an appliancedevelopment toolkit according to the invention showing a step in thecreation of a message data payload using holders.

FIG. 36 is a screen shot of a model instance editor in an appliancedevelopment toolkit according to the invention showing another step inthe creation of a message data payload using holders.

FIG. 37 is a schematic diagram showing the use of holders in different avariable model according to the invention.

FIG. 38 is a schematic diagram showing a first scenario showing therelationships of variables.

FIG. 39 is a schematic diagram showing a second scenario showing the useand relationships of holders.

FIG. 40 is a schematic diagram showing a third scenario showing the useand relationships of holders.

FIG. 41 is a schematic diagram showing the use of paired elements instain treatment in an appliance according to the invention.

FIG. 42 is a schematic diagram showing the use of development toolkitsaccording to the invention with an appliance in the creation of cycleinstances for the appliance.

FIG. 43 is a schematic diagram of a substitution model instance createdaccording to the invention.

FIG. 44 is a schematic diagram showing the relationship between a cycleoutcome model instance and sequence model instance according to theinvention.

FIG. 45 is a schematic diagram showing the relationship among instancevariants, user interface controls, and models according to theinvention.

FIG. 46 is a schematic diagram showing a dynamic rendering of agraphical user interface in response an appliance receiving data from asender according to the invention.

FIG. 47 is a schematic diagram showing the use of a test engine todiagnose an appliance according to the invention.

FIG. 48 is a schematic diagram showing the use of sequence modelinstances and cycle outcome model instances in meal planning accordingto the invention.

FIG. 48A illustrates a sequence model instance for recipes in FIG. 48.

FIG. 48B illustrates a sequence model instance for substitutions in FIG.48.

DESCRIPTION OF EMBODIMENTS OF THE INVENTION

Referring to the drawings and to FIG. 1 in particular, an appliancedevelopment toolkit 10 according to the invention, which will bereferred to hereinafter as the toolkit 10, is configured to enable thecreation and modification of content 20 to affect and/or effectoperation of one or more components associated with an appliance 12 soas to affect and/or effect interaction between a user 14 and theappliance 12 and/or a cycle of operation of the appliance 12. Thetoolkit 10 can be used with different appliances 12 without requiringthe recoding of software of the toolkit 10. The user 14 can be aconsumer, a salesperson, a manufacturer 14A (see FIG. 25), a productengineer, or any other individual capable of using the appliance 12and/or the toolkit 10.

The appliance 12 can be any suitable appliance, such as a householdappliance. Examples of household appliances include, but are not limitedto, clothes washing machines, clothes dryers, ovens, dishwashers,refrigerators, freezers, microwave ovens, trash compactors, andcountertop appliances, such as waffle makers, toasters, blenders,mixers, food processors, coffee makers, and the like.

The appliance 12 can be configured to perform a cycle of operation tocomplete a physical domestic operation on an article. Examples of thephysical domestic operations include a food preparation operation, afood preservation operation, a fluid treatment operation, a cleaningoperation, a personal care operation, a fabric treatment operation, anair treatment operation, and a hard surface treatment operation. The airtreatment operation can comprise, for example, air purification, airhumidification, air dehumidification, air heating, and air cooling. Thefood preparation operation can comprise, for example, food cleaning,food chopping, food mixing, food heating, food peeling, and foodcooling. The food preservation operation can comprise, for example, foodcooling, food freezing, and food storage in a specialized atmosphere.The fluid treatment operation can comprise, for example, fluid heating,fluid boiling, fluid cooling, fluid freezing, fluid mixing, fluidwhipping, fluid dispensing, fluid filtering, and fluid separation. Thecleaning operation can comprise, for example, dishwashing, fabricwashing, fabric treatment, fabric drying, hard surface cleaning, hardsurface treatment, hard surface drying, carpet cleaning, carpettreatment, and carpet drying. The personal care operation can comprise,for example, hair treatment, nail treatment, body massaging, teethcleaning, body cleaning, and shaving.

The components associated with the appliance 12 can include any devices,parts, software, and the like that participate in the operation of theappliance 12, either directly or indirectly. Some of the components havea corresponding controller (main controller, motor controller, userinterface, etc.), which can be a simple microprocessor mounted on aprinted circuit board (a control board), while other components can haveno controller. The components can comprise one or more devices that arecontrolled by the controller. Typically, the controller components incooperation, either directly or indirectly, through other components,control the operation of all of the components and the associateddevices to implement a cycle of operation for the appliance 12.

The one or more components affected/effected by the toolkit 10 cancomprise another appliance 12, one or more components on the appliance12 or in another appliance 12, or an accessory device or componentthereof for use with the appliance 12. For purposes of describing theinvention, it will be understood that when reference is made herein tothe use of the toolkit 10 in conjunction with the appliance 12, the sameapplies to the use of the toolkit 10 in conjunction with anotherappliance 12, with one or more components of the appliance 12 or ofanother appliance 12, and with an accessory device or component(s)thereof for use with the appliance 12.

The appliance 12 can be communicatively coupled to the toolkit 10 via acommunications network 18 existing at least partially within theappliance 12 and/or at least partially external to the appliance 12 asappropriate. The communications network 18 comprises all of the couplingelements communicatively linking the various parts of the toolkit 10 andthe appliance 12, as well as any coupling elements communicativelylinking additional devices or resources to the toolkit 10 and/orappliance 12 (e.g. a coupling element connecting the appliance 12 withan accessory). For example, the communications network 18 can comprisean internal communications network of the appliance 12 enablingcommunication between the various components within the appliance 12, anexternal communications network connected to the toolkit 10, and acoupler for communicatively coupling the two networks. The coupler cancomprise a communication driver configured to establish a communicationslink between the toolkit 10 and the appliance 12. Looking also at FIG.2, the communication driver can be a smart driver 54 having expandedfunctionality enabling the smart driver 54 to create, modify, and/orinterpret content 20. The communications network 18 can furthercomprises an additional communications connection between the appliance12 and/or toolkit 10 and one or more additional devices, such as theaccessory, an external network, a second appliance 12 or accessory, orone or more components thereof. As a non-limiting example, theadditional communications connection can be to the Internet. Thecommunications network 18 can comprise, at least in part, a smartcoupler 56 as is disclosed in International Patent ApplicationPublication No. 2009/058770, which is incorporated by reference hereinin its entirety. The smart coupler 56 can incorporate the communicationsdriver, which can be the smart driver 54.

The toolkit 10 enables a user 14 to create content 20 that can beprovided to or otherwise obtained by one or more content targets 22 toaffect the functionalities of the appliance 12. Content 20 can beformatted as at least one of a relational database, XML document, CSVfile, binary file, data collection, memory structure, object structure,object graph, object tree, memory heap, machine code, source code, andtext file, images, text, data elements, or other type of informationassociated with the toolkit 10 that can be interpreted, converted,propagated, created, modified, or otherwise used for some purpose by thetoolkit 10, the appliance 12, or an associated device or component.Examples of content 20 include but are not limited to a cycle structure,a custom cycle, a branded cycle, user-attached data about appliancecontrol functionality, a fault tree, a diagnostic test, an applianceuser interface 64 (see FIG. 6A for example), appliance networkcommunication, routing tables for appliance network communication, staintreatment, cooking, cooking algorithms, cooking vessels, mealpreparation, dish preparation, recipes, units conversion, ingredients,ingredient substitution, dietary needs, appliance use and care,appliance FAQ, consumables meta data, and information associated withconsumable, a cycle definition, cycle structure information, a pairedelement, source identification information, a message data payloadstructure, an electronic document that is human-readable,machine-readable, a communications specification/protocol, andinformation about a consumable.

Content 20 can comprise various forms of data or data elements,including appliance user domain data 180 (see FIG. 24), control systemdomain data 182 (see FIG. 24), and source identification domain data 186(see FIG. 46). Appliance user domain data 180 includes informationrelated to a user's 14 use of an appliance 12. It includes such thingsas washing and cooking preferences, recipes, user demographics, choicesand selections that user makes, and the like. Control system domain data182 includes information related to the control and operation of anappliance. It includes such things as cycle structures, cycledefinitions, message payloads, communication protocols, and the like.Source identification domain data 186 includes information related tothe sources of goods and services and includes things such astrademarks, brand names, service marks, jingles, and the like. Userinterface domain data includes information related to interacting with auser interface 64, which is preferably a graphical user interface 68. Itincludes such things as widgets, animation definitions, buttons, bars,sliders, knobs, and the like, whether real or virtual.

A content target 22 comprises any entity that receives content 20.Non-limiting examples of different content targets 22 include thetoolkit 10, the appliance 12, the communications network 18, a systemconfigurator 28, editors 30 and 32, converters 34, viewers 38, anappliance control system 90, a user interface 64 and graphical userinterface 68, a web browser or web page, a personal computer 70, anapplication 50, a computer program, a handheld device, a remote client72 such as a cell phone, a printer, and any hardware or softwarecomponents or devices associated therewith or included therein.

As shown in FIGS. 2-4, the toolkit 10 comprises system configurator 28having a model editor 30, a model instance editor 32, and one or moreconverters 34 configured to enable a user 14 to create, modify, and/orpropagate content 20, such as models 40, model instances 42, and modelinstance variants 44, respectively. The toolkit 10 can further compriseone or more viewers 38 that function as content targets 22 and provide avisual display corresponding to the received content 20. Depending onthe particular type of viewer 38 being used, viewers 38 can produce oneor more of a variety of different displays or views ranging fromschematic diagrams to code to images. The communications network 18 isconfigured to establish a communicative link between the systemconfigurator 28 and at least one component associated with the appliance12.

Different content targets 22 can use the same content 20 for differentpurposes. For example, a model instance editor 32 that receives content20 in the form of a model instance 42 can provide a visual diagram ofthe model instance 42 and enable the user 14 to edit the model instance42. However, if the same model instance 42 is sent to the appliance 12,the appliance 12 can be enabled with new operational capabilities, suchas new cycles of operation. In another example shown in FIGS. 5 and 6A,the appliance 12 can receive the model instance 42 from the modelinstance editor 32 and provide the model instance 42 to a graphical userinterface 68 of the appliance 12 in order to cause the graphical userinterface 68 to display certain images and text.

Converters 34 can enable the flexible usage of content 20 by convertingdata elements or content 20 created by one of the editors 30, 32 intocontent 20 of a form suitable for use by a particular content target 22.For example, a type of converter 34 called a model instance converter isconfigured to produce a model instance variant 44 based on a modelinstance 42. Another type of converter 34 called a simple converter cansimply propagate data elements or a file stored in memory and comprisingdata elements created by the toolkit 10 without having to substantiallyconvert the data elements. Simple converters are best used when thecontent target 22 can operate directly on the data elements created byeditors 30, 32, such as a content target 22 in the form of a viewer 38included in the system configurator 28. Converters 34 are typically usedto enable the transfer of data elements amongst the various entities ofthe toolkit 10 and appliance 12. A converter 34 can potentially also actas an exporter, which functions similarly to the propagating functiondescribed previously. The toolkit 10 can also include a converter 34 inthe form of an encoder to encode content 20 onto a consumableinformation holder or other component.

The system configurator 28 can optionally further comprise one or moreapplications 50, which can also include one or more viewers 38 and canuse content 20 provided by the system configurator 28. One or moreapplications 50 can also be communicatively coupled to but not includedwithin the system configurator 28. Content 20 provided by the systemconfigurator 28 can optionally be supplemented by content 20 provided byor created using resources 46, which can include any entities capable ofproducing content 20 or being used by another entity to generate content20.

For testing, diagnostic, and engineering purposes, a link can beestablished between the system configurator 28 and a content targetsimulator 52 (FIG. 2). The content target simulator 52 typicallycomprises software and is intended to provide a realistic simulation ofthe operation of the appliance 12. The toolkit 10 thus comprisessoftware configured to enable a user 14 to effectively command operationof the appliance 12 or of an appliance simulator and to create data ordata elements for display to a user 14 as content 20 in a viewer 38 ofthe toolkit 10 based on the operation of the appliance 12. The user 14can observe the content 20 in the viewer 38 and create or modify thecontent 20 using the toolkit 10 in response to communication over thecommunications network 18 and link.

A model 40 is a very robust, thorough, and thoroughly-vetted collectionof data elements or structures equivalent to a UML class diagram. Amodel 40 consists of a plurality of class definitions where each classhas a plurality of properties and each class can reference other classesa minimum and maximum number of times, which may be infinite. Classescan reference other classes via a named property. Classes can also, ineffect, serve as extensions of other classes in order to inherit theirfunctionalities, property definitions, and references. Classes canimplement interfaces, which are definitions of collections of functionseach having a set of arguments, wherein each argument can be set to oneof a set of valid values. The purpose of the class definition is toprovide rules or constraints for creating model instances 42 and modelinstance variants 44, which are, in essence, runtime instances of themodel 40. Thus, the toolkit 10, in effect, enables users 14 to createruntime instances of a class diagram and is configured to create,manage, and/or edit models 40, model instances 42, and model instancevariants 44, as well as data elements or information associatedtherewith, that are configured to effect the functionality of one ormore components associated with the appliance 12.

As described in more detail hereinafter with respect to FIGS. 25 and 26,the model editor 40 is typically used by a user 14 associated with themanufacturer 14A of the toolkit 10 or of the appliance 12, such as anengineer or software developer, to refine and constrain models 40 priorto the models 40 being made available to users 14 external to themanufacturer 14A. The provides the manufacturer 14A with the ability tocontrol the specific toolkit 10 functionalities available to users 14outside the company, and, in doing so, provides the ability for themanufacturer 14A to offer and sell licenses for the toolkit 10 thatenable users 14 access to only certain levels of functionality. Eachparticular model 40 in essence is a template or a plurality ofconstraints defining at least part of the functionality of the systemconfigurator 28. Each model 40 enables at least one model instanceeditor 42 and defines the functionalities of the model instance editor42. Thus, n models 40 can be used with the toolkit 10 to generate ninstances of data elements derived therefrom. An exemplary data elementcan comprise at least one representation of a portion of a message datapayload to be sent across the communications network 18.

The model instance editor 42 creates instances of data elements thatcomprise a model instance 42 and that are related to appliance 12functionality and derived from the appliance user domain data 180 model.The model instance editor 42 is configured at least in part by theappliance user domain data 180 model irrespective of the appliance 12 sothat the toolkit 10 can be used with different appliances 12. Validationrules, which essentially comprise a communications protocol, for thecontent 20 can be derived from the appliance user domain model. Themodel instance 42 can comprise a hierarchical data structure, a graph, afault tree, or a relational database and can be configured or developedby a user 14 interacting with the user interface 64.

Referring now to FIGS. 5-7, models 40 can be grouped into a variety oftypes based on the function of the model 40 and model instances 42created therefrom. A user interface domain data model 40A can be used tocreate user interface domain data model instances 42A, such as thatillustrated in FIGS. 5 and 7, which are used to control thefunctionality of a user interface 64 of the appliance 12, which can be agraphical user interface 68. In this example, the user interface domaindata model instance 42A includes user interface control objects 60A-Cdisplayed in the model instance editor 32 and corresponding to each ofthree user interface controls 62A-C to be displayed on the userinterface 64 of the appliance 12. The user interface control objects60A-C are converted or propagated by a converter 34 included in thesystem configurator 28 into content 20, which is sent to a contenttarget 22 of the system configurator 28, the viewer 38. Looking now toFIG. 6A, the viewer 38 then creates a rendering of the graphical userinterface 68 as it would appear on the appliance 12 once the userinterface domain data model instance 42A has been sent to the appliance12 as content 20. This simulation enables the user 14 to observe and, ifdesired, modify the appearance of the graphical user interface 68without having to repeatedly reprogram the appliance 12 itself. Asillustrated in FIGS. 6B and 6C, the user interface domain data modelinstance 42A can also be sent to other content targets 22, such as apersonal computer 70 or a remote client 72, as content 20 to enable theuser 14 to visualize the user interface 64 and tailor the user interface64 to his or her particular needs and tastes.

A sequence model 40B as shown in FIG. 7 is another type of model 40 thatcan be used to create cycles, fault trees, recipes, and tests (see alsoFIG. 47). As described herein, the same sequence model 40B can be usedto generate a variety of different types of sequence model instances(e.g. instances for a cycle, a fault tree, a recipe, or a test). In somealternative embodiments, multiple sequence models can be required togenerate the different types of sequence model instances. A sequencemodel instance for a cycle 42B that is derived from the sequence model40B is illustrated as a content target 22 of the user interface domaindata model instance 42A. In this example, an object 60A of the sequencemodel instance for a cycle 42B corresponding to a user interface control62A for dispensing ice is propagated or, if necessary, converted by aconverter 34 associated with the user interface domain data modelinstance 42A or sequence model instance for a cycle 42B into theappropriate format and is provided to the sequence model instance for acycle 42B.

Due to this binding of user interface domain data of the user interfacedomain data model instance 42A and control system domain data 182 of thesequence model instance for a cycle 42B, when a user 14 actuates theuser interface control 62A, the transition will be initiated, and thecycle specified by the sequence model instance for a cycle 42B andcreated in the manner explained below will be carried out to produceice.

Objects can be composed of a plurality of other objects according to theobjects field definitions. If an object comprises a method which hasexecutable software to set the value of a field defined to hold anobject, then that object can be reconfigured by changing the value ofthe a field from a first object to a second object. This reconfigurationcan then result in a different composite or overall appliance controlsystem 90 behavior. There are many useful purposes for an appliancecontrol system 90 whose behavior can be changed by changing the valuesin a first objects field to a third object from a second object. Forexample, a cycle accessory could use this technique to change a cyclestructure 80. Likewise, both a consumables reader and a recipe book wandcould use these techniques to customize the behavior of the appliancecontrol system 90 according to appliance user domain data 180, sourceidentification domain data 186, user interface domain data the dataabout the cycle, data about a consumable, and the like.

There are many mechanisms which can initiate and manage the dynamicconfiguration of an appliance control system 90. However, thesemechanisms (see FIG. 34) will need a common design framework with whichto accomplish the dynamic configuration. Some portions of the dynamicconfiguration can be accomplished during the compile process, whileother portions may be accomplished at post-compile time (also known asruntime).

FIG. 7 illustrates several ways that the appliance 12 can obtaininformation necessary to carry out appliance 12 operation, includinginformation about cycles of operation, and generate a cycle structure toperform a cycle of operation. Here, cycle structure information 82represents information about or associated with a cycle structure 80 tobe produced by the cycle engine 88. Cycle structure information 82 caninclude modifications to be made to an existing cycle structure 80,information to be used to create a new cycle structure 80, or a cyclestructure requiring conversion or some sort of manipulation into a cyclestructure 80 suitable for use with the particular appliance 12. Cyclestructure 80 represents a set of instructions for use by the appliancecontrol system 90 of the appliance 12 for carrying out a cycle ofoperation. An exemplary appliance control system 90 is illustrated inFIG. 9 and is described in detail by International Patent ApplicationPublication No. 2006/135758, which is incorporated by reference hereinin its entirety. In one embodiment, the cycle structure 80 can becreated by using messaging for communicating the cycle structureinformation 82 to the cycle architecture 86 via the communicationsnetwork 18, at which point the cycle engine 88 can discover informationfor creating or modifying cycle structure 80 for use by the appliancecontrol system 90. The cycle engine 88 then proceeds to build a new ormodified functional cycle structure 80. Optionally all messages can berouted through an embedded virtual router (EVR) 92, which results in thecycle engine 88 using its own configuration API for building the new ormodified cycle structure 80. The execution by the cycle engine 88 tocreate or modify the cycle structure 80 can also be accomplished throughthe EVR 92.

An arbitrary software component 94 in communication with the cycleengine 88 or in communication with the cycle architecture 86 can also beused to create a new or modified cycle structure 80. The arbitrarysoftware component 94 can reside in a variety of locations with respectto a controller component comprising the cycle architecture 86. Hence,all messages between the arbitrary software component 94 and the cyclearchitecture 86 can be optionally routed through an EVR 92 across thecommunications network 18. As well, the cycle architecture 86 canoptionally communicate with the appliance control system 90 through anEVR 92.

In another scenario, an operational cycle accessory, such as the toolkit10, can be communicatively coupled to the communications network 18,discover the cycle architecture 86, and send the cycle architecture 86messages to affect its structure and, ultimately, its execution. In thiscase, the operational cycle accessory would typically include acombination of software and data to accomplish the configuration of thecycle architecture 86. Alternately, the aforementioned cyclearchitecture might send a discovery message seeking identification ofall sources of the cycle structure 80. Sources of the cycle structuremay be in ROM, Flash, EE Prom, an operational cycle component, and/or anexternal source connected to the communications network 18. Once thecycle structure information 82 located and retrieved, the cycle engine88 can commence modifying its own cycle structures 80 according to thenew cycle structure data. As shown in FIG. 7, when the converters 34associated with the cycle structure information 82 and the cyclestructure 80, read the sequence model instance for a cycle 42B, theconverter 34 associated with the cycle structure information convertsthe sequence model instance for a cycle 42B into cycle structureinformation 82, and the converter 34 associated with the cycle structureconverts the sequence model instance for a cycle 42B directly into acycle structure 80. Both the cycle structure information 82 and thecycle structure 80 generated by the associated converters 34 aregenerated based on the same content 20 comprising the sequence modelinstance for a cycle 42B.

In another embodiment of a cycle architecture 86, a first portion of thecycle structure information 82 is compiled and a second portion is madeavailable at runtime. The second portion can include a plurality ofcycle structure data, either in direct or indirect form, which can becombined with the first portion such that the cycle engine 88 operateson the aggregate of the first and second portions to create operationalcycle execution software. The second portion can represent differencesin the first portion where differences may be additions, deletions, ormodifications to elements, their relative orders, or their relativerelationships within the cycle structure 80. The cycle engine 88 canappropriately apply the differences represented in the second portion bylooking at the identifiers of the elements of the first portion of thecycle structure information 82 and the identifiers of the elements ofthe second portion of the cycle structure information 82. The advantageof this embodiment of a cycle architecture 86 is that changes to theaggregate cycle structure 80 can be made while preserving the firstportion such that subsequent corruption or absence of the second portionwould not effect the integrity of the first portion, thus enabling theoperation cycle execution software to revert to compiled default state,such as might be supplied at the factory. A second advantage of thisembodiment is that specialized variants of the first portion can bedesigned which can accommodate the constraints presented by theappliance control system 90 and more specifically the controllingcomponents of the appliance 12 such as limited memory and also providecapability for receiving and adapting to a second portion, providingflexibility and configurability within the constraints for the cost ofthe specialized variants. For appliances 12, this can be an importantrequirement in some cases.

Alternatively, when an operation cycle accessory is disconnected fromthe cycle engine 88, the data of the second portion can be optionallyremoved by the cycle engine 88, causing a reversion to the factorydefault state. This is a form of anti-piracy protection in that theoperation cycle accessory must be present for the additionalfunctionality represented by the accessory to be available to theappliance 12. Optionally, the connection between the appliance 12 andthe operation cycle accessory can include a transfer of the firstportion into a memory in the appliance 12. In this case, additionaloperation cycles can be retained without the permanent presence of theoperational cycle accessory. It should also be noted that an operationcycle accessory can be virtual in that the software and data and abilityto communicate with the cycle engine 88 can reside on an external deviceconnected to the cycle engine 88 via communications network 18, and notphysically attached to the containing appliance 12.

It is to be noted that an operational cycle component can have otherelements that are not the aforementioned operation cycles or constituentdata and complied portions. For example, the operational cycle componentcan include software code to configure a cycle engine 88 forcommunication and other functions or code to put software architectureinto an alternate mode for the purpose of diagnostics or changingmemory.

An appliance cycle of operation performed by the appliance controlsystem 90 can be optimized by information associated with consumables onwhich the appliance is operating. For example, the cycle structure 80could be built specifically to accommodate some properties or attributesof the consumable or to accommodate some properties or attributes of aconsumable holder. The body or bodies that comprise information,identifiers of functionalities, properties, attributes, and property andattribute values related to consumables can be referred to as sources ofinformation about a consumable or “consumable information holders.”Examples of consumable information holders include the consumableitself, a data pod, the consumable holder, a user interface, and a tag.The consumable holder can be a sensing consumable holder that might usea lid sensor, for example, for sensing attributes about the consumablecontained therein. These attributes could then be used by the appliance12 to further refine operation of the consumable holder. For example, ifa particular consumable holder is supposed to dispense 2 ounces, a lidwith an amount sensor could be configured with an analog circuit coupledto the appliance 12 to provide a level or volume feedback so that theappliance 12 can dispense exactly 2 ounces rather than a time-basedapproximation.

Information associated with a consumable can include amount and/orcomposition or other attributes that would characterize the magnitude ofthe usefulness of the consumable. In this case, the cycle architecture86 may adapt itself based on the information. For example, if theconsumable were a dishwashing rinse aid and the consumable holder hadonly 90% of the standard dose, the cycle architecture 86 might adaptitself to this condition by increasing the time of the rinse phase tocompensate for the lack of rinse aid. Information associated with aconsumable can also include parameters of an operating cycle such aspersonal preferences of a user 14 (e.g., doneness or crispinesspreferences), and data about the consumable holder, the appliance 12, orother accessories or components thereof.

In a laundry example, the appliance control system 90 may provideinformation to the cycle architecture 86 about process variables likesoil level, load size, soil type, etc. Based on this informationassociated with a consumable, including the process variableinformation, the cycle architecture 86 or an arbitrary softwarecomponent 94 in conjunction with a cycle engine 88 can reconfigure thecycle structure 80 to adapt to the process variable information. Theconsumable holder may comprise the arbitrary software component 94 andbe able to reconfigure the cycle structure 80 to adapt to the processvariable information. Reconfiguration can be accomplished in at leasttwo ways. In one way, the arbitrary software component 94 can read thecycle structure 80 and communicate with the cycle engine 88. In a secondway, an arbitrary software component 94 can be preconfigured andcommunicate that configuration to or instruct the cycle engine 88 aboutthe configuration.

One example of commands associated with an operating cycle is acollection of key value pairs. Keys comprise parameter names having ameaning, wherein the meaning is known by the cycle engine 88 such thatvalues associated with the keys are thereby associated with themeanings. This enables the values to be used in the contexts of themeanings to modify and/or control the cycle of operation of theappliance 12.

Another example of commands associated with an operating cycle is a bytearray representing a message packet for a network. In one embodiment ofthis example, the byte array could be arranged according to the packetdefinition disclosed in WO2006135726 comprising a functional identifier,an op code, and a message data payload, wherein the identifier and opcode relate to an executable function or method implemented by the cycleengine 88 and or cycle engine API. Further, the arguments or parametersof the function or method correspond to the data elements contained inthe payload of the message packet.

The consumable holder, therefore, can contain all the functionality ofand participate in all the embodiments that an operational cycleaccessory in communication with an appliance 12 having a cyclearchitecture 86 can. Therefore in one embodiment, a consumable holder isan operation cycle accessory that further physically contains and canalso further be enabled to directly actuate the introduction of aconsumable into an appliance 12.

As seen in FIG. 8, content 20 can be derived from or provided bycomponents or resources 46 outside the appliance 12 (external content20) or from memory or other information contained within the appliance12 (internal content 20) and acquired by a content 20 acquisitioner 102.Appliance software framework 104, which includes the cycle architecture86 of FIG. 7, receives the content 20 and creates appliance controlfunctionality 100. The appliance control functionality 100 provides andcontrols the user interface 64 and user interaction, as well as providesand controls the appliance control system 90. As an example, FIG. 9 alsoillustrates the appliance control system 90 disclosed in InternationalPatent Application Publication No. 2006/135758 and further includes thesystem configurator 28 for managing the functionality thereof.

As shown in FIGS. 10-15, sequence model 40B can also be used to generatea sequence model instance for a fault tree 42C. Appliances 12 are oftendiagnosed and serviced using an appliance fault tree 110, and thesequence model instance for a fault tree 42C serves to present a user 14with various displays or views on the user interface 64 informing theuser 14 of possible problems and solutions associated with the appliance12. The initial step of an appliance fault tree 110 will normally beassociated with a symptom of failure or state of the appliance 12.

With continued reference to FIGS. 10-15, the exemplary initial step isperformed upon determination of a state of the appliance 12 in which theuser 14 is experiencing slow or no water dispensing. Each step of theappliance fault tree 110 including the initial step can have one or moreassociated actions. Actions can be various tasks or checks performed ateach step. Exemplary actions can comprise, but are not limited to,taking a measurement, asking a question, requesting user input,describing an observation, and the like. The exemplary action associatedwith the initial step is to ask a question, “Is the refrigeratorconnected to a water supply?” The action can also comprise obtaining theanswer, which can be “Yes” or “No.”

Transitions are paths to other steps in the fault tree 110 and that arenormally conditional on the result of a given step or action. At eachstep of the sequence model instance for a fault tree 42C, an action canbe performed comprising asking a question regarding operation of theappliance 12, and the question can be presented on the user interface64. Once an answer to the question has been obtained, the sequence modelinstance for a fault tree 42C will perform a transition to another stepin the appliance fault tree 110. As shown in FIG. 11A, each questionwill also have corresponding content 20 that is displayed on the userinterface 64. Typically, question-based content 20 will include buttonsor other user interface controls 62D, 62E that will enable the user 14to input an answer to the question. Alternatively, the appliance 12 canautomatically determine the answer to the question using variouscomponents, such as sensors. Thus, an answer can be obtained either viauser interaction with the appliance 12 via the user interface controls62, or an associated device, or automatically by the components of theappliance 12 or an associated device.

As shown in FIG. 10, when an answer of “Yes” is obtained when theinitial step is carried out, the appliance fault tree 110 can transitionto the next step. Thus, the question and answer function as argumentsthat, in combination, form a conditional statement in the appliancefault tree 110. While proceeding through the appliance fault tree 110,the specific steps, actions, and transitions are performed based onwhether the various conditional statements in the appliance fault tree110 are true or false. If a conditional statement is false, notransition will occur, and the appliance fault tree 110 will proceed inorder. If a conditional statement is true, then a transition can beperformed, which can act as a path to a particular step, action, and/ortransition. In some cases, the action can be displaying a solution onthe user interface 64.

As shown in FIG. 10A, an answer determination attribute editor 120,which is also a component of the model instance editor 32, can be usedto edit the content 20 displayed to the user 14 at a given transitioncorresponding to a given question and answer conditional statement. Theanswer determination attribute editor 120 is illustrated as having anumber of well-known elements frequently included in computer-basedediting applications, such as clickable buttons 122, a display window orviewer 38, and a text entry box 124.

As shown in FIGS. 12-15, the sequence model instance for a fault tree42C can also be used to present a use and care guide 130 to the user 14via the user interface 64 of the appliance 12, which can comprise theGUI 68. Content 20 comprising text to be displayed to the user 14 can becreated using a document model instance 42G (FIG. 43) for a use and careguide 130, which specifies content 20 can be displayed on the userinterface 64 that enables a user 14 to select a symptom 132 included inthe use and care guide 130. The selection of a symptom 132 canautomatically bias the user 14 to an entry or starting point in thesequence model instance for a fault tree 42C so that the user 14 doesnot have to waste time looking through irrelevant symptoms. In addition,a given appliance 12 can have more than one fault tree 110 associatedwith it. For example, there can be a fault tree 110 associated withdifferent components or different subsystems in the appliance 12. Therecan also be different fault trees 110 associated with accessoriesconnected to the appliance 12, and each fault tree 110 can have aninitial step A that would normally serve as the starting point for entryinto the respective fault tree 110. It may be, and often is the case,that any given fault tree 110 for an appliance 12 might have multipleentry points. Further, a transition, as discussed previously withrespect to FIGS. 10-15, is not limited to transitioning to a sequentialstep within the same fault tree 110. For example, a transition from afirst step on a fault tree 110 can lead to a second step on anotherfault tree 110.

The fault tree 110 and/or use and care guide 130 provided by thesequence model instance for a fault tree 42C can also be presented in aviewer 38 as content 20 in the form of a diagram 140 as shown in FIGS.14 and 15. The user 14 can troubleshoot problems by simply using acontent target 22 capable of presenting the content 20. For example, asshown, a user 14 can use the personal computer 70 to view a web pageincluding the information, or the user can use a printer 142 to printout a copy of the diagram 140. In either instance, the sequence modelinstance for a fault tree 42C can be used to diagnose problems andpotentially find a solution without requiring a visit from aserviceperson.

Looking now to FIGS. 16-23, a message data payload model instance 42D isused to manage message data payloads 150 comprising a first portion 152having usable data and a second portion 154 having information todescribe the usable data. The first and second portions 152, 154 cancomprise an ordered collection of message elements 156 or at least onemessage element 156. One of the first and second portions 152, 154 canhave a direct or indirect reference to the other of the first and secondportions 152, 154, which can effectively bind the portions. Theconstraints defined by the model 40 can be used within the modelinstance editor 32 to create the association between the first andsecond portions 152, 154. Various message elements 156 can be compiledto create a portion 152, 154 using the model instance editor 32 duringcreation of the message data payload 150 and can comprise meaningfultext describing the meaning of the message element 156. Usable data fromthe communications network 18 can be combined with non-usable datadescribing the usable data wherein the user 14 can understand themeaning of the usable data. Based on the message data payload modelinstance 42D and the properties 158 thereof, a viewer 38 can display acomplete specification 160 that updates in real time as the user 14edits the message data payload model instance 42D and propertiesthereof.

Specifically, FIGS. 16-18 show the creation and advantages of useabledata in the inventive appliance development toolkit 10. The systemconfigurator 28 displays the message data model instance 42D in themodel instance editor 32, a viewer 38 showing properties 158, and aviewer 38 showing the specification 160. Elements and choices of acommand structure or sequence are created in the model instance editor32 as an instance of a message data payload 150. A first portion 152 ofa message element 156 comprises useable data and is set in byte 1. Asecond portion 154 identifies the first portion 152 and is set in thusexample in byte 0. The model instance editor 32 can have constraintsthat limit or guide what a use can do in creating message payloads 150.In any event, the model instance editor 32 creates an associationbetween the first and second portions 152, 154 where rules for datarepresentation provided by the communications network 18 over which themessage payload 150 is to be sent provide the constraints.

A user interface 64 or viewer 3 can display a visualization of themessage data payload 150 from the model instance editor 32 so that auser 14 can conveniently create the message data payload 150 forimmediate use and see a graphical representation of the message datapayload 150 as it is created. An example of that display is seen inFIGS. 17 and 18. In FIG. 17, a viewer associated with an application 50can display relevant data including the identifiers (second portion). Asshown in FIG. 18, a specialized viewer 38 associated with an application50 or, alternatively, incorporated directly into the system configurator28 can also be associated with a command generator 170 such that theassociated viewer 38 displays the various message elements 156 of themessage data payload 150 and the command generator 170 enables the user14 to define and initiate the sending of a message data payload 150 toaffect the operation of the appliance 12. The command generator 17 caninclude one or more buttons 122 for initiating the sending of a definedmessage data payload 150.

FIGS. 19-23 show in steps the creation of a message data payload modelinstance 42D using variables, values, and value holders, which will bedescribed in more detail hereinafter in FIG. 37. See the description ofholders, infra. As well, FIG. 20 shows the use of menus 174 and forms176 for guiding or limiting a user 14 in selecting and inputtinginformation according to the constraints. An error message 172 can bedisplayed if a property 158 or parameter associated therewith isincorrect or improper according to the constraints. A model instanceeditor 32, which includes constraints as will be discussed in moredetail hereinafter, is constrained by a model 40. In FIG. 20, an APIobject has been selected and the user 14 has right clicked the object,bringing up menu 174 having an “Insert New” feature. Referring to amessage data payload model 40C of FIG. 37, an API is allowed to have aminimum of zero relationships with a message data payload 150 and amaximum of n or infinite relationships with a message data payload 150.Therefore, if the user selects the “Insert New” item on the menu 174, asub-menu (not shown) or form 176 can appear, enabling the user 14 tochoose to create a message data payload object. In this case, the modelinstance editor 32 reads the model 40 such that it is informed by themodel 40 what the possible relationships between each current andpotential objects are so that the model instance editor 32 editor canconfigure its functionality from the information in the model 40 so asto constrain itself according to the model 40. In this way, aconstrained appliance development toolkit 10 constrained by a model 40can limit the types of objects created and the available relationshipsbetween objects which in turn limits the ability to create content 20,which in turn limits the appliance control functionality.

FIG. 24 illustrates types of model instances 42 that can be associatedor bound by the model instance editor 32 of the appliance developmenttoolkit 10. Essentially anything in the different domains of data can bebound for later use. Although appliance user domain data 180 and controlsystem domain data 182 are here shown, it will be understood thatbinding among other domains is equally within the scope of theinvention, e.g., user interface domain data 184 and/or sourceidentification domain 186 data.

FIG. 25 illustrates the benefit of constraining the development toolkit10 for use by users who want to create content 20 for effecting thecycle of operation of the user interaction of an appliance 12 but do nothave all the engineering skills or knowledge to do so. The constraineddevelopment toolkit 10 enables a user 14 that has less than all therequired knowledge or skills to create content 20 that effects the cycleof operation or the user interaction of an appliance 12 wherein theeffect is less than the full effect that content 20 from anunconstrained appliance development toolkit 10 can create. Theconstraints used to constrain use of the toolkit 10 can be specifiedwithin a model 40. It is to be understood that for the purposes ofdescribing the invention, unless otherwise specified, reference to thetoolkit 10 herein can be understood as a reference to a constrainedtoolkit and/or an unconstrained toolkit.

Appliance manufactures build appliances for a competitive market andcompete with one another in the areas of cost and innovation.Accordingly, manufacturers 14A must continuously invest in new products,new technologies, and new innovations while simultaneously reducing costand improving quality. The ability of an appliance manufacturer 14A todevelop a means by which to engage thousands of additional persons forthe purpose of creating new product innovation without raising costswould be a disruptive competitive advantage for that manufacturer 14A.However, because only highly trained and specialized engineers cansuccessfully and properly create appliance control functionality,previous attempts by manufacturers 14A to engage the thousands ofadditional persons in an uncontrolled manner have not resulted in theproduction of functional and properly-engineered appliance controlfunctionality. As appliance control functionality plays a critical rolein a person's everyday life, such as by affecting the clothes peoplewear, the food they eat, and the air they breathe, proper implementationof appliance control functionality is a necessity. Many appliancecontrol functionalities are also potentially dangerous and must beprecisely managed by the specialized and intricately engineeredappliance control system, such as appliance control functionalitiesassociated with high voltage sources, high heat sources, gases, liquids,and chemicals.

The use of constraints to contrain the appliance development toolkit 10enables the thousands of additional persons to create content 20 thateffects and/or the cycle of operation or the user interaction of anappliance by providing guidelines and rules for innovation. Inparticular, the constraints can enable users 14 to create content 20that effects/affects only certain appliance control functionalitiesdeemed appropriate for manipulation by the manufacturer 14A whilepreventing users 14 from creating content 20 that effects/affects theappliance control functionalities associated with critical systems andcomponents of the appliance 12. This enables the manufacturer 14A toensure that the appliance 12 is safe for use by maintaining theintegrity of the core appliance control functionalities. For example,the manufacturer 14A would constrain the toolkit 10 so as to preventusers 14 from manipulating precision controls, such as those for highheat, electricity, or harmful substances, so that the food, clothing,air, or other article or elements is properly operated upon by theappliance 12.

As shown in FIG. 26, there are three approaches to providing aconstrained appliance development toolkit 10. They are through aconstraining model 40, a constraining model instance 42, and hard-codedconstraints, which can comprise content 20 as previously described.Constraints define at least a portion of the functionality of theconstrained appliance development toolkit 10. It is generally the modelinstance editor 32 of the system configurator 28 which uses theconstraints to partially limit and partially control the functionalityand therefore the content 20 which the system configurator 28 is able tocreate.

As shown in FIG. 28 and in FIGS. 7 and 8, appliance controlfunctionality can be created from content 20 generated from an appliancedevelopment toolkit 10. This is also shown in FIG. 25 via first content20 and second content 20 created by the appliance manufacturer 14A and auser 14 respectively.

Referring back to FIG. 25, the appliance manufacturer 14A may provide aconstrained development toolkit 10 which is hard-coded. The appliancemanufacturer 14A can also use an unconstrained toolkit 10 to create thethird content 20, which can include a constraining model 40, aconstraining model instance 42, or both. In the latter two cases, theconstrained appliance development toolkit 10 uses the third content 20to define at least a portion of the constraints.

Referring back to FIG. 26, it is generally the model instance editor 32of the system configurator 28 which uses the constraints to partiallylimit and partially control the functionality and therefore the content20 which the system configurator 28 is able to create. The message datapayload 150 instance may have been created by an unconstrained modelinstance editor 32 or by a constrained model instance editor 32. Thesystem configurator 28 of the appliance development toolkit 10(unconstrained and constrained) is able to load multiple model instance42 files in model instance editors 32 for the creation of andassociations between objects.

A constrained model instance editor 32 constrained by hard-code is shownin FIG. 26. This approach can achieve the same results as the other twoapproaches, but at a higher development cost over time because each newmodel 40 or each new model instance 42 interaction needs to behard-coded. The previous two approaches rely on a data driven approachwith is lower cost over time.

FIG. 27 includes an illustration of using a constraining model instance42. On the right side of the model instance editor is a sequence modelinstance for a cycle 42B for a washing machine. The model instanceeditor 32 is being used to create a custom cycle with the sequence modelinstance for a cycle. As shown, the custom cycle includes a transitionfrom the idle state to the fill tub state wherein the action object forthe fill tub state is responsible for the exact control actions to betaken when the fill tub state is entered. In an unconstrained toolkit10, the user 14 can specify any control action from the universe ofcontrol actions as the action to be taken in the fill tub state.However, the constrained toolkit 10 includes an message data payloadmodel instance 42D which provides a set of control actions less than theuniverse of control actions such that the user can associate at leastone command from the message data payload model instance 42D with thefill tub action object of the sequence model instance for a cycle 42B inorder to define the control action to be taken when the fill tub stateis entered. Note that the level limit on the fill level message element156 is between 20 and 80%. This prevents the user 14 from specifying avalue for fill level either above 80% or below 20%.

FIG. 28 depicts the appliance development toolkit 10 interacting with anappliance 12 via its appliance software framework 104 by way of content20 created by the toolkit. In this embodiment, the content 20 is createdby one or more model instance converters 34 and includes a builder file190 and a plurality of resources 192, which can comprise one or moreresources 46. A resource 192 can be a data set containing data. Aresource 192 can be a file or collection thereof, a database, a streamof streaming data, an event source, a network connection forcommunicating data and the like. In all cases, the nature of the datafor a resource 192 ranges from images and videos to XML, relationaldatabases, language conversions, and animation definitions.

Consumers/users 14 enjoy dynamic user interfaces 64, especiallygraphical user interfaces 68. Even better are multi-media interfacesthat combine audio, visual, and tactile stimuli to create the ultimateuser experience. However, users 14 keep their appliances for 10-12years, and as such it is desirable to provide a variety of userexperiences over time to keep the user 14 engaged and excited about theuser experience of the appliance 12. The capability to update andtransform a multi-media user interface 68 on an appliance 12 isdesirable. Themes 194 are collections of resources 192 which can beapplied to the components or controls of a multi-media user interface 68through a mapping at runtime. Themeing is the application of themes 194to the multi-media user interface 64 at runtime such that that the userinterface 64 transforms dynamically in response to the application 50.

Similarly, the capability to create a very dynamic user experiencewherein a plurality of user interface controls or stimuli cause otherplurality of user interface stimuli to trigger is desirable. Moreover,an additional feature is to have the different pluralities of userinterface stimuli related through a mapping so that when the mappingchanges, the user experience also changes. An animation framework 196includes animation execution software and animation definitionsconnected to other components of the appliance software framework 104,including properties of the UI controls 62 so that the rendering of theUI controls 62 is affected by the animation execution software operatingon the animation definition.

In both cases of themeing and animations 198, creating associationsbetween resources 192, animations, themes 194, and user interfacecontrols 62 is essential and complex. The appliance development toolkitof FIG. 28 is configured to create the necessary object representationsand associations therebetween in order to generate the content 20necessary for the appliance software framework 104 to build the objectsat runtime, including UI controls 62, animation definitions (i.e.objects), data objects from resources, and objects which associate orbind the aforementioned together to achieve the dynamic graphical andmulti-media user interface 68 for the appliance 12.

The main output of the toolkit 10 in this embodiment is a builder file190. The builder file 190 contains information including objectidentifiers, object type (class) identifiers, and relationships betweenidentifiers so that a builder 200 in the appliance 12 can read the fileat startup or on demand and create the runtime object collections,hierarchies, graphs that control the dynamic graphical and multi-mediauser interface 68 for the appliance 12. The builder file 190 isgenerated by a model instance converter 34 that traverses the modelinstance objects resident in the toolkit 10 memory and exports thebuilder file 190 content 20 in response. The user interface domain datamodel instance 42A includes instances of objects from the user interfacedomain data model 40A, which includes class definitions for pages anduser interface controls 62 and the relationship definitionstherebetween.

A view or page 202 contains one or more pages, and a user interfacecontrol (UI control) 62 contains one or more UI controls 62. Pages areobjects that display a plurality of user interface components and aregenerally designed to be navigated to and navigated from. UI controls 62are generally reusable templates of components that must be combinedwith data at runtime to create a useful control. UI controls 62 arethings like buttons, knobs, slider bars, select boxes, text boxes, checkboxes, image frames, movie frames, input windows, and the like. UIcontrols 62 have a plurality of properties which are named components ofthe UI control 62 which either receive or emit data. It is also possibleto think of a UI control property as a variable wherein the identifierof the variable would be UI control identifier, property identifier(i.e., UI control identifier, control property identifier). Examples ofUI control properties are font, color, style, size, data, shrinkable,hideable, hide, and the like.

The behavior, rendering, visualization and functionally of a UI control62 is affected by its properties. UI controls 62 can also emit datawhich can also be associated with a property. Examples of propertiesinclude current data, state 246, current size, current state ofvisibility and the like. By connecting or associating UI controlproperties to representations of variables known as data sources orbinding objects 204 at runtime, the UI control 62 is able to be affectedby other actors in the appliance software framework 104 and to beeffectively rendered. Additionally, the connection to properties is ableto affect other actors in the appliance software framework 104 which areconnected to or are listening to property values of a UI control 62. Forexample, a tactile animation can be listening to a pressed property of aUI control 62 so that when the press property is true, the tactileanimation executes. The aforementioned UI controls 62, their properties,representations of variables, binding and actors objects, and therelationships therebetween are created by the builder 200 in response tothe builder file 190.

To accomplish both themeing and animations, the appliance developmenttoolkit 10 creates a representational hierarchy of objects which can beexported to the builder file 190 and read by the builder 200 to createthe aforementioned runtime objects of the appliance software framework104. First the toolkit 10 is configured to create objects representingruntime UI controls 62 and to associate a data source identifier 206with certain properties of the created UI controls 62 wherein the datasource identifier 206 is later associated with a resource identifier 210to create a first binding map, binding map 1. Next, a set of resourcedictionaries 212 are created each having a plurality of resourceidentifiers 210 and where each resource identifier 210 is associatedwith a file identifier 214, which can comprise an address to a resource192. The file identifiers 214 can be in the form of a URI, URL, URN,path, and the like. Different resource dictionaries 212 can contain thesame resource identifier 210 associated with a different file identifier214, thereby creating the basis for themeing.

The toolkit 10 can also be configured to enable the user 14 to associatea plurality of theme identifiers 216 each with one or more resourcedictionary identifiers 218 in a second binding map, binding map 2, sothat when a theme 194 is selected at runtime, data for application to aproperty of a UI control 62 can be acquired by finding the address ofthe data through the use of the information contained in binding map 2,binding map 1 and the resource dictionary 212.

Referring still to FIG. 28, at runtime, the builder 200 reads thebuilder file 190 and creates the UI control objects and associates themas shown in FIG. 29 with data sources 204. Binding objects/data sources204 are created for each unique data source identifier 206 in thebuilder file 190 and locator objects or resource binding objects 220 arecreated for each unique resource identifier 210 in the builder file 190.The binding objects 204 are associated with the properties of the UIcontrol objects according to the builder file 190 and associated withthe resource binding objects 220 according to the builder file 190 Theaddresses of file identifiers 214 associated with the resourceidentifiers 210 in the resource dictionaries 212 corresponding to thecurrently selected theme 194 are set into the resource binding objects220 so that the resource binding objects 220 can acquire the data fromthe resources 192 when requested.

Using this arrangement, a theme manager 222 applies a newly selectedtheme 194 by creating new resource binding objects 220 and associatingthem with the appropriate binding objects 204 according to theinformation in the builder file 190. In this manner, a user 14 of thetoolkit 10 can construct multiple mappings between resource data, UIcontrol properties, data streams, animations, and media files, such thatchanging a the mappings results in a dynamic transformation to thegraphical or multi-media interface 68 of an appliance 12.

There can be multiple types of resource binding objects 220. An SQLbinding object will know how to execute SQL against a database found atthe address of its associated locator resource binding object 220. Amedia binding object may know how to un-marshal a binary media file of acertain type. There can also be binding objects pointing to controlsystem domain data 182 associated with the cycle of operation enablingeither the UI control objects and or the animation definitions tointeract with the appliance control system 90, appliance softwareframework 104, and cycle of operation.

A special type of resource 192 is a language resource. By choosing atheme 194, the graphical user interface 68 can transform between a firstand second language. Also because of the many to many relationshipsbetween two or more of the theme identifiers 216, resource dictionaries212, and resources identifiers 210 are composable, a theme 194 can haveresources 192 supporting a Spanish Christmas, and another theme 194could have resources 192 supporting a Spanish victory in the soccerWorld Cup, wherein there can be one resource dictionary 212 for theSpanish language, one for Christmas, and one for Soccer.

Animations 198 work the same way as do other resources 192. Animations198 can have two binding points, an input and output. The output of ananimation 198 is a function of its input value determined by its bindingand its f(x) function, which can be any mathematical function. Thebinding to an animation is depicted in FIG. 28 wherein the animation isbound to two data sources 204 in the form of resource binding objects220, as well as to an animation binding object. In effect, the animation198 acts like a resource 192 of FIG. 29 having its input connected toone resource binding object and its output connect to anther resourcebinding object. When the theme manager 222 changes themed animations198, it creates two new resource binding objects, sets an address of thenew animation definitions (either input or output) into each of the newresource binding objects, and optionally loads the animation 198 intomemory for execution.

Additionally, the toolkit 10 can construct resources 192 for access bythe appliance software framework 104. The appliance 12 can also have aninterface for receiving a new builder file 190 and/or new resources 192and can either combine or interchange the new and the existing files sothat the appliance 12 can be updated over time with new pages 202, newthemes 194, new animations 198, and new resources 192.

Looking now to FIGS. 30-42, in a first embodiment, a hierarchy ofobjects starts with a single root object that we can call “root.” Theroot object has 0 to n children and the children may be of differenttypes (i.e., type 1 and type 2). In turn, the 0 to n children may alsohave children. Therefore, an object A that is a child of root and haschildren of B and C is considered to be both a child and a parent andcan be referred to either as a child or a parent depending on thecontext. Except for the root, all objects in a hierarchy are a child andthose with children are also parents. The root is a parent unless it hasno children.

The first embodiment is a simple example of an implementation of ahierarchy wherein the parent child relationships are directrelationships. In a direct parent child relationship, the parentincludes an identifier identifying each of its children. Therefore, theparent cannot be decoupled from its children because it comprises theidentifiers of its children.

A second embodiment exemplifies an indirect parent child relationshipwherein neither the parents nor the children include identifiers of theother. Instead, a holder object contains the identifiers of both. Forexample, object Q is a holder and contains an identifier of object A,object B, and object C, wherein object A is of type 1, object B is oftype 2 and object C is of type 3. Objects A, B, and C do not have accessto the identifiers of one another. The primary responsibility of objectQ is to contain identifiers for objects A, B, and C thereby establishingthat there is some type of relationship between objects A, B, and C.There are a number of ways that the nature of the relationship betweenA, B, and C can be ascertained. In a first example, object Q has accessto information defining the possible relationships between objects oftype 1, 2, and 3. In this example the information would define a firstrelationship definition between objects of type 1 and type 2 as being aparent-child relationship wherein type 1 must be the parent and type 2must be the child. The information would also define a secondrelationship definition between objects of type 1 and objects of type 3as being a parent-child relationship wherein type 1 must be the parentand type 3 must be the child. With the information, object Q caninterpret the relationship between object A, B, and C as a parent withtwo children wherein A is the parent of children B and C.

A third embodiment exemplifies an alternate approach for creating anindirect parent child relationship wherein neither the parents nor thechildren include identifiers of the other. In this embodiment, multipleholders are used to create a holder hierarchy. For example, object Q isa holder and contains an identifier for object A. Object Q also containsan identifier for a second holder object X. Object X contains anidentifier for object B. Holder object Q is a parent holder with respectto holder object X because holder object Q contains the identifier toholder object X. Therefore the relationship between object A and objectB be can be inferred as a parent child relationship when observed fromthe perspective of holder object Q and holder object X because holderobject Q are in a direct parent child relationship. In this case, objectA and object B are in an indirect parent-child relationship.

A forking element includes a hierarchy having a first parent object withat least two children where at least one of the two children has one ormore second children and where the one or more second children have oneor more third children. An interpreter of the first parent, the one ofthe two children, the one or more second children, and the one or morethird children interprets the two children as valid values of the parentand interprets that the one or more second children is applicable to thehierarchy when the first parent is paired with the at least one of thetwo children that is the parent of the one or more second children

FIG. 30 illustrates a set of direct parent child relationships having anexample of a forking element as part of a message data payload modelinstance 42D. The First Element of Byte 0 has two valid values, FirstChoice and Second Choice. Second Element is a child of First Choice andThird Element is a child of Second Choice. Given this arrangement, whena message data payload 150 corresponding to the illustrated message datapayload model instance 42D is transmitted on a network as part of anetwork message, the value of Byte 0 would determine the meaning of Byte1. For example, if the useable data transmitted in Byte 0 correspondedto the first portion of useable data associated with First Choice, thenan interpreter or user of the network message could ascertain that Byte1 contained useable data associated with the second portion of theSecond Element rather than Third Element.

In an extension of the first example exemplifying a nested forkingelement, the Second Element also has two children Third and Forth Choicerespectively each having a child Forth and Fifth element respectively.Here an interpreter or user of the network message could ascertain themeaning of Byte 2 by looking at the useable data found in Byte 1 andassociating the useable data of Byte 1 with corresponding second portionof Byte 2. For example if the useable data of Byte 1 corresponded to theuseable data of Third Choice, an interpreter could then determine thatthe meaning of the useable data found in Byte 2 would correspond to thesecond portion of the Forth Element. A forking element comprising atleast one additional forking element creates a nested forking element.

FIG. 37 shows a plurality of models 40 that form a simplified UML classdiagram that includes examples of relationship definitions includingboth direct and indirect parent child relationships. It should be notedthat a UML class diagram defines possible relationships between futureinstances of objects derived from at least one class definition bydepicting an arrangement of relationship definitions used to definerelationships between class definitions where the possible relationshipsare a function of the relationship definitions. A UML class diagram isuseful because the arrangement of and relationships between each of thefuture instances of objects derived from at least one class definitionmay be verified and or at least partially predicted using the UMLdiagram.

Generally, in an appliance runtime environment, variables 230 areidentifiers which have an associated value 232 where different actors inthe runtime system set the value 232 of the variable 230. However, FIG.37 depicts additional possibilities for expanded use of variables 230and their values 232 and illustrates the benefit of holders.

In some cases, a variable 230 can have a relationship with a value 232where, for example, the relationship depicts a request for the variable230 to be set to the value 232 at a future time. In other cases, avariable 230 could be associated with a plurality of values 232 in orderto depict the possible values 232 of a variable 230 at some future time.

Yet in other cases, as in forking elements within a message data payload150 or a capabilities definition, values 232 are parents of othervariables 230. Relationships like this are useful to express hierarchiesof choices 234, variable validation, payload validation, commandvalidation, user interface behavior, etc. For example a hierarchy ofchoices 234 might have a root of question 1 with choices A and B aschildren, where choice A has a child of question 2 having choices of Cand D as children. This hierarchy could be used to drive a wizard, suchas the use and care guide 130, such that the answer to question 1 woulddictate if another question would need to be asked. For example, if theanswer to question 1 was choice A, then question 2 would need to beasked to get an answer of either choice C or choice D. However, ifchoice B were the answer of question 1, then no further questions wouldbe necessary. Using this technique, the behavior of the wizard could becontrolled by the capability definition and an answer sheet comprisingthe list of questions asked and the answers given could be validatedusing the capability definition.

Looking again at FIG. 37, the previous example illustrated by FIG. 30can be understood in the context of the message data payload model 40Cshown in FIG. 37. Also shown is that components of the message datapayload model 40C extend or inherit from class definitions in variablemodel 40D. A message element 156 can be a variable 232 or it can be avariable holder 236. Also, choices 234 and variable definitions 238extend a value abstract class 240.

Using the previous example of FIG. 30 and applying it the model of FIG.37, a forking can occur when an abstract value 242, such as a choice234, has a child of a variable 230, like a message element 156, which isshown to be a potential arrangement in that a choice 234 extends anabstract value 242 via abstract value class 240, and that abstract value242 can have a variable 230 as a child, and that message element 156extends or is a message element 156. These relationship definitions asshown in the simplified UML class diagram define the possibility to havemessage elements 156 having children of choices 234 with those choices234 having children of other message elements 156 as shown in FIG. 30,which shows an instance of the message data payload model 40C of FIG.37.

However, it can be undesirable to have direct parent child relationshipsbetween variables 230 and their values 232 as shown in FIG. 30 and asallowed by the model 40D of FIG. 37. As shown in FIG. 37, a variableholder 236 can include a reference to a variable 230 and a value 232. Inthis way, an indirect parent child relationship can be formed asdescribed in the second embodiment exemplifying an indirect parent childrelationship (above) and as shown in the first and second occurrences ofFIG. 39, where a first holder 236 holds a reference to a first parentvariable 230 and a first child value 232 and a second holder 236 holds areference to the first parent variable 230 and a second child value 232.FIG. 39 shows that by using the first and second holder objects, thefirst parent variable can participate in two different indirect parentchild relationships; one with the first child value 232 and the otherwith the second child value 232.

Additionally, as shown in FIG. 37, another embodiment shows how anindirect parent child relationship can be formed. According to thefigure, an instance of a variable holder 236 can also include areference to an instance of an object that derives from the abstractvalue class 240, which includes value holder 244, value 232, variabledefinition 238, and choice 234. And an instance of value holder 244 caninclude a reference to an instance of an object that derives from valueabstract class 240. In this way, an indirect parent-child relationshipcan be formed as described in the third embodiment exemplifying anindirect parent child relationship (above) and as shown in the third andforth occurrences of the third and second hierarchies in FIG. 40,respectively, where in the third occurrence, a first variable holder hasa reference to or holds a first parent variable 230 and has a referenceto or holds a second value holder 244 which then has a reference to orholds a first child value 232. In this way an indirect parent childrelationship is formed between the first parent variable 230 and thefirst child value 232 via the direct parent child relationship betweenthe first variable holder 236 and the second value holder 244. Likewisein the 2nd hierarchy, the first parent variable 230 is shown for a forthtime in the forth occurrence (first and second occurrences from FIG. 39)in a similar indirect parent child relationship as is shown in the thirdhierarchy but with a second child value 232. FIG. 40 illustrates avariable 230 participating in two indirect parent child relationshipswhere each relationship involves a different child by using variableholders 236 and value holders 244 as prescribed by the variable model40D of FIG. 37.

Additionally, as shown in FIG. 37, the value abstract class 240 isdefined as having a direct parent child relationship with variableholders 236 or variable 230. This is the enabling model relationshipdefinition that supports the forking element of FIG. 30 as well as therelationship between Value: Wool: 4 and Attribute: Delay: Default=0 ofFIG. 38.

FIG. 37 also illustrates the model 40 for the capabilities model 40F ofan appliance 12. FIG. 38 illustrates a capabilities model instance 40Fcomprising a hierarchy of variables 230 to values 232 and variables 230to variable definitions 238 in repeating direct parent childrelationships. This hierarchy known as a capabilities tree is a child ofthe state 246 object idle, meaning that when the appliance 12 is in anidle state, the hierarchy contained by state object idle represents theoperational capabilities of the appliance 12 from a command and controlperspective. From the command perspective, all valid commands can bederived by observing and interpreting the hierarchy. A command, in itssimplest form, is a message that results in one appliance variable 230being set to a value 232. The variable 230 and the value 232 togetherare referred to as a paired element 252 (also shown in FIG. 41). In manycases however, a valid command to an appliance 12 includes a pluralityof interdependent variables 230 each having a value 232 selected from aplurality of valid values 232 and wherein the selection of the values232 determines a portion of the other interdependent variables 230 thatalso must be specified with a value 232 to form a well formed command orcommand container 250.

As previously described in the hierarchy of choices 234 example, theappliance capabilities model 40F can be used to determine whatadditional interdependent variables 230 must be included in a commandcontainer 250 based on the selected value 232 of each variable 230.Command containers 250 have at least one paired element 252. A commandcontainer 250 may be validated by traversing the capability tree toobserve and verify that each of the variables 230 or variable holders236 in the command container 250 is one of a root of the tree and aparent in the tree wherein the parent is a value 232 or value holder 244as part of the plurality of paired elements 252, to observe and verifythat each paired element 252 is located at one of the root or a directdescendent of another paired element 252 connected to the root, and toobserve and verify that at least one paired element 252 comprises avalue 232 or value holder 244 as a leaf node of the tree. As shown inFIGS. 41 and 42, a cycle definition, then, includes a command container250 wherein the content 20 of the command container 250 affects thecycle of operation of the appliance 12 when the appliance 12 runtimesets the variables 230 specified by the command container 250 to thevalues 232 specified in the command container 250. Other informationincluded in the cycle definition can be used for graphical userinterface 68 rendering and other non-control system domain purposes.

The capabilities model instance 42F of FIG. 38 is an example of usingonly direct parent child relationships between variables 230 and values232. However, according to FIG. 37, a different embodiment usingvariable holders 236 and value holders 244 can be constructed (similarto FIG. 40) where the capabilities model instance 42F would comprisevariable holders 236, variables 230, value holders 244, and values 232.

It is apparent, by observing FIG. 38, how value holders 244 and variableholders 236 could provide improvement to the compatibility of the twomodel instances 42D, 42F. Just as in FIG. 37, the variable model 40Dprovides some common base classes for use by the message data payloadmodel 40C and the capabilities model 40, Content 20 includes variables230 and values 232 arranged in a nested repeating hierarchy of alternatelevels of variables 230 having values 232 and value having variables230. However, because direct parent child relationships are used in themodel instances 42D, 42F, herein referred to as scenario 1, there isless reuse than could be accomplished if variable holder 236 and/orvalue holders 244 were used as in scenario 2 and scenario 3 of FIGS. 39and 40, respectively. Referring the variable ‘Cycle’ in the capabilitiesmodel instance 42F and the element ‘cycle’ in the message data payloadmodel instance 42D, it can be observed that these two informationelements are the same logical entity. In both cases, the elements referto the memory variable 230 in the appliance runtime which corresponds toone of the selected, request, and active cycle of the appliance 12.However, the capabilities model instance 42F contains a completevalidation hierarchy as exemplified by the ‘Delay’ variable 230underneath the ‘Wool’ value 232. By contrast, the message data payloadmodel instance 42D on the right has two hierarchies, one for the ‘cycle’and one for the ‘Delay’ because the designer of this context made achoice to arrange the information into separate hierarchies. Therefore,because the information is in multiple hierarchies and is partitionedand organized differently, the information must be duplicated inseparate information elements as shown in Scenario 1.

However, if the information were created using the previously describedtechnique of Scenario 3 of FIG. 40, the information would not requireduplication and the information elements or identifiers thereof (i.e.variables 230, values 232, message elements 156, choices 234, variabledefinitions 238, etc.) could be re-used throughout multiple hierarchieseach have a different context. Using this approach then, the multiplecontexts can leverage information from the multiple contexts becausethere are common or shared objects within those contexts which can beused to gather information across multiple contexts by using the sharedobjects as navigation objects for jumping from and jumping to differentcontexts. This is further explained and exemplified by FIG. 40 and thedescription thereof.

For example, an appliance 12 can communicate its operationalcapabilities to a client by sending a capabilities model instance 42F tothe client. The client can then form a command container 250 and sendthat command container 250 back to the appliance 12. The appliance 12can take the variables 230 from the paired elements 252 of the commandcontainer 250 and validate the command container 250 by traversing thecapabilities tree as previously described. Once validated, the appliance12 can automatically convert the command container 250 into one or moremessage data payloads 150 for constructing network messages to executethe command container 250 across multiple control boards communicatingon the communications network 18. This automatic conversion andvalidation is enabled by using variable holders 236 and value holders244 to construct the capabilities and message data payload modelinstances, 42F and 42D, respectively.

When variables 230 and values 232 participate in more than onehierarchy, wherein each hierarchy has a context different from the otherhierarchies, it is difficult to only use direct parent childrelationships. For this reason, the UML class diagram of FIG. 37 depictsa variable model 40D wherein a user 14 can use either of the at leastone variable holder 236 and the at least one value holder 244 increating at least one hierarchy of elements for content 20 independentof any relationship that may otherwise exist between the variable 230and other elements and between the value 232 and other elements so thatthe variable 230 and the value 232 can be used in different contextswith different relationships while maintaining their relationship witheach other via the at least one variable holder 236 and the at least onevalue holder 244.

FIG. 42 depicts the use of an appliance development toolkit 10 a firstset of constraints creating a first set of content 20 with which asecond user 14 using an appliance development toolkit 10 having a secondset of constraints could use to create a cycle definition 262. Aspreviously described a cycle definition 262 includes a command container250 with at least one pair element 252 derived from a collection ofappliance variables 230 and values 232. The appliance namespace includesa collection of uniquely identifiable and meaningful variables 230 foran appliance 12. Therefore the user 14 of the toolkit 10 with the secondset of constraints could create a cycle definition 262 by selecting datafrom the appliance model instance 42J shown in FIG. 42, which comprisesa plurality of model instances 42 used by the appliance 12, andspecifically from the appliance namespace 260. As the user 14 constructsthe cycle definition 262, the toolkit 10 can validate the cycledefinition 262 using the capabilities model instance 42F. The user 14can associate data about the cycle definition 262 including sourceidentification domain data 186 which includes brand emblems and otherlicensable data or other data including usage text, help, and one ormore identifiers of persons, consumables, and articles, and the like.

FIG. 43 illustrates the use of a document model instance 42G within adomain model instance 42H interacting with a converter 34 to createcontent 20 for display in a viewer 38. The purpose of a document model(not shown) is to enable a user 14 to use the model instance editor 32to create and view content 20 associated with a domain model instance42H within the system configurator 28 before final export to a contenttarget 22. In a sense, the viewer 38 is a content target simulator 52.

A domain model (not shown) is an abstraction or model 40 associated withreal world constructs like cars, buildings, trees, law, language, media,finance, and just about any topical concept imaginable without respectto non-domain concerns like formatting, language, style, persistenceform and the like.

In FIG. 43 the domain model instance 42H is an ingredient substitutionmodel and the non-domain model instance is the contained document modelinstance 42G shown in the dashed box. As shown, the document modelinstance 42G is an arrangement of objects (shown under the UITextobject) including markup objects for formatting, special objects forcreating spaces or punctuation, text objects for creating static content20, and domain objects able to contribute content 20 based on theirproperties, functionality, and composition.

A converter 34 traverses the arrangement to create html content 20 forthe internet browser based viewer 38 on the right. In this way, a user14 can specify the behavior of the content target 22 with respect to thecontent 20 by creating data for simulation of the content target 22.Additionally, viewing the content 20 aids the user 14 in understandingthe meaning of the domain model 40H in that a portion of the viewablecontent 20 is a function of the domain model 40H. Therefore the content20 and viewer 38 together help the user 14 validate and verify thecomposition of the domain model 40H.

FIG. 44 depicts binding between appliance user domain data 180 andappliance control system domain data 182. As shown, a cycle outcomemodel instance 421 for cooking comprising a food identifier, a vesselidentifier and a doneness identifier is bound to a cycle structure 80identified by SCF5 wherein when the content 20 is generated for theappliance 12 from the cycle outcome model instance 421 and the sequencemodel instance for a cycle 42B, and appliance control functionality ofFIG. 8 is created by the appliance software framework 104 of FIG. 7 andFIG. 28. A user 14 can affect the cycle of operation by selectingelements of the user interface domain data 184 rendered on the userinterface 68 and bound to the cycle structure 80 identified by SCF5.

In this way, the graphical user interface 68 of FIG. 46 can display thesource identification domain data 186 and other data on the userinterface 64 of the appliance 12 in response to the identifiers eithersensed from a sensor like a scanner or selected via the appliance userinterface 64. Moreover, as previously discussed, the cycle definition262 can be automatically translated into transmittable network messages266 by a message generator 264 of FIG. 45 using the message data payloadmodel instance 42D of FIG. 42 and FIG. 45.

FIG. 47 shows an example of how an appliance development toolkit 10according to the invention is used in interaction with a user 14 and anappliance 12 to diagnose an appliance 12. It further shows additionalexamples of the use of a constrained toolkit 10 using model instances 42as the constraining component. The toolkit 10 is configured to createone or more test scripts 270 having at least two steps, each step beingseparated from its adjacent steps by a transition condition thatincludes a logic expression resolvable to a Boolean transition value, atleast one command statement associated with one of the at least twosteps that instructs what should happen when the at least one step isthe current step so that a test engine can execute the at least onecommand statement contemporaneous with the transition of the at leastone step from the current step to the next step. The toolkit 10 alsoprovides information associated with at least one message element 156 ina message data payload 50 so that the message data payload 50 isuniquely identifiable within a universe of pre-defined message datapayloads 50 for the appliance 12. (See the foregoing discussion ofidentifiers.) A converter 34 will place the test script 270 into a formto be readable or at least useable in diagnosing an appliance 12.

There will be associations of command statements and message elements156 created by the toolkit 10 so that a test engine application 50A cancreate a command container 250 based on the test script. Commandstatements will include such things as questions to a user such as shownin FIGS. 11-15. Holders 236, 244 as discussed elsewhere are useful toolsfor the editor 10 to effect flexibility in creating command sequencesfor the test script 270. The test engine application 50A is configuredto observe subsequent network messages 266 and relate those to atransition logic in the test script 270, and to evaluate the logic fortransition to the next step as it traverses a hierarchy in the testscript 270.

In one embodiment, a second a communications driver can be configured toestablish a communication link with the test engine application 50A, anda fault tree tool application 50B is configured to access one or morefault trees 110 to construct a command container 250 on instructions inthe fault tree(s) 110 and to convey the command container 250 to thetest engine application 50A via the second communication link duringexecution of a command statement in the fault tree 110.

So it can be seen that a model instance editor 32 can use the messagedata payload model instance 42D to create the data that a model instanceeditor 32 uses, along with a sequence model instance for tests 42K, tocreate the test script (which is a sequence model instance variant). Thetest engine application 50A uses the test script 270 in communicationwith a smart coupler 56, such as a smart cable, to communicate with theappliance 12 and with the user 14. Meanwhile a model instance editor 32uses a sequence model instance for a fault tree 42C to create a sequencemodel instance variant, such as a fault tree, that a fault tree toolapplication 50B uses in interaction with the user 14.

A sequence model instance for tests 42K is similar to other instancesusing the sequence model 40B in that it allows the user 14 to create aset of steps separated by transition conditions having logic to drivethe condition where each step has an associated action specifying thetasks to be done in that step. A sequence model instance for tests 42Kcan use message data payload model instances 42D as constrainingelements for the actions in each step. This is accomplished in a similarfashion previously described for FIG. 27 wherein the message datapayload model instance 42D is used to constrain a sequence modelinstance for a cycle 42B.

Referring back to FIG. 47, the sequence model instance for a fault tree42C is constrained as well using the sequence model instance for tests42K wherein each test in the sequence model instance for tests 42K mighthave an identifier or an identifying test object that can be bound tothe action of a step in the sequence model instance for a fault tree 42Cat tool time such that when the fault tree tool application 50B reachesa step wherein a test script 270 should be executed, it can communicatewith the test engine application 50A to invoke the test script 270corresponding to the identification of the test object at runtime.

The test engine application 50A, having been previously constrained byelements from the message data payload model instance 42D and havingactions of steps bound to message data payload model instances 42D canuse the binding to automatically construct and transmit useable messages266 from the test engine application 50A to the appliance 12 using themethod as previously described for cycle definition 262 translation tomessage data payloads 150.

FIGS. 48, 48A, and 48B illustrate binding between multiple instances ofuser domain data 180 to control system domain data 182, which isillustrated at a high level in FIG. 23. The control system domain data182 comprises a cycle outcome model instance 421, 42B and a sequencemodel instance for a cycle 4B that can be used for a cycle structure 80for a cooking appliance 12. To achieve a desired outcome, a set ofcooking profiles (FIG. 44) are created each having multiple componentsspecifying various parameters associated with the cooking cycle.

To get the doneness of crispy donuts, the profiles in FIG. 44 indicatethat the user 14 needs to use an iron skillet in a 30″ cavity, and inthe other case we have a glass crock pot in a 27″ cavity; thus, a user14 can cook those donuts differently to achieve the same outcome, andthe desired cycle outcome will point to the specific sequence for thecycle. Different profiles and different cycle structures 80 cantherefore achieve the same outcome given a set of appliance user domaindata 180 elements like the food type, cavity size, and the pan.

Using the recipe specified by one of the sequence model instance for arecipe with a first set of portions 42L and the sequence model instancefor a recipe with a second set of portions 42M, the selection of whichis based on the cooking profiles, the user 14 first gets theingredients. In this example, the user 14 is using the sequence modelinstance for a recipe with a first set of portions 42L: get 5 ounces offlour, 2 ounces of sugar. The sequence model instance for a recipe witha first set of portions 42L then transitions to the next state 246called mix. The user 14 then mixes the ingredients and transitions tothe next state to cook. The user 14 puts the mix in the pan and formsthe dough, gets a pan, places the dough in the donut forms in the pan,and then transitions into state cook, where the user 14 places the panin the appliance 12 and uses the user interface 46 to select the foodpan and doneness to select the cycle.

The ingredients substitution model 40N and instance 42N thereof are bothappliance user domain data 180. For a portion of flour, there is analternate portion of crushed seaweed, and a substitution object in theingredients substitution model instance 42N holds the primary andalternate portion and enables a user 14 to substitute one for the otherand still complete the desired cooking cycle.

Likewise, we have a second substitution that shows a substitutionbetween sugar and Splenda. So the arrows between the ingredients and thealternate portions and the substitution window point up to both thesequence model instance for a recipe with a first set of portions 42Land the sequence model instance for a recipe with a second set ofportions 42M, and as seen in the sequence model instance for a recipewith a second set of portions 42M, the ingredients automatically changedout the ingredients from 5 ounces of flour to 60 ounces of crushedseaweed and from 2 ounces of sugar to 4 ounces of Splenda. Thisrelationship between these models/model instances enables the user 14 tofluidly accommodate issues that arise during cooking.

The alternate portion can also have nutritional information associatedtherewith so that as sequence model instance for recipes call forcertain portion substitutions, the nutritional information is derivedfrom the portions and then compared that to the constraints from themeal planner discussed below, allowing the meal planner to then actuallyachieve the substitutions based on nutritional constraints.

As shown in FIG. 48, this ability to transform and suggest a recipecomprises a meal planner that can query other smart agents ofinformation to figure out how to best plan the meal. The meal can alsobe a combination of multiple recipes, such as a lasagna followed bydonuts for dessert. The meal planner will thus query for theparticipants in the meal, each person's schedules, the profiles of theparticipates to note food preferences, allergies, diets, and doctor'sorders that would create constraints on the meal planner. The mealplanner will then use the information garnered from these queries toselect either certain recipes or certain ingredients for recipes toconform to the preferences of the people, the schedules of the people,or the nutritional constraints that people might have based on theirdiets, allergies, etc.

The other constraint that a meal planner could look at would be aninventory system constraint where an inventory system actually knows theavailable portions that are in the house and then the meal planner couldtake that and select recipes or do ingredient substitutions or recipesbased on the inventory at hand. It could also populate a shopping listif there were certain things that it highlighted as not being availableor being in conflict with a preference of a person or a diet of aperson, then it could kind of spit out a shopping list and say to theuser of the meal planner, hey, we better get this. And of course itcould automate that transaction by having it ordered, delivered, etc.

While the invention has been specifically described in connection withcertain specific embodiments thereof, it is to be understood that thisis by way of illustration and not of limitation, and the scope of theappended claims should be construed as broadly as the prior art willpermit.

1. An appliance development toolkit to enable creation of content toaffect operation of a component in an appliance or to affect userinteraction with an appliance, the toolkit comprising: one of applianceuser domain data and source identification domain data, an editor tocreate instances of data elements related to functionality of anappliance or to functionality of the editor derived in part from the oneof the appliance user domain data and the source identification domaindata, an interactive user interface on which the editor is displayed foruse by a developer, and a converter to generate content using the dataelements created by the instance, wherein the editor is configured atleast in part by the one of the appliance user domain data and sourceidentification domain data irrespective of the appliance so that theappliance development toolkit can be used for different applianceswithout recoding.
 2. The appliance development toolkit of claim 1wherein the one of the appliance user domain data and the sourceidentification domain data derives from a model and the editor is amodel instance editor configured to create instances of the model,wherein the editor derives constraints from the model so that the editorcannot create a model instance incompatible with the model.
 3. Theappliance development toolkit of claim 1 wherein the converter is anexporter to export at least a portion of the data elements as thecontent.
 4. The appliance development toolkit of claim 1 furthercomprising a second one of appliance user domain data and sourceidentification domain data wherein the editor can create secondinstances of data elements derived from the second one of the applianceuser domain data and the source identification domain data.
 5. Theappliance development toolkit of claim 4 wherein the editor enablescreation of associations between instances of data elements derived fromthe one of the appliance user domain data and the source identificationdomain data, and instances of elements derived from the second one ofthe appliance user domain model and the source identification domaindata.
 6. The appliance development toolkit of claim 5 wherein theconverter creates content including related portions of the instances ofdata elements derived from the one of the appliance user domain data andthe source identification domain data, and the instances of dataelements derived from the second one of the appliance user domain dataand the source identification domain data wherein the operation of thecomponent in the appliance or the interaction between a user and theappliance is affected by the related portions.
 7. The appliancedevelopment toolkit of claim 6 wherein the related portions includecooking vessels and a cooking outcome.
 8. The appliance developmenttoolkit of claim 6 wherein the related portions include cooking vesselsand food to be cooked.
 9. The appliance development toolkit of claim 6wherein the related portions include clothes and their soil conditions.10. The appliance development toolkit of claim 6 wherein the relatedportions include clothes and a cycle outcome.
 11. The appliance ofdevelopment toolkit 10 wherein the cycle outcome is associated with oneof time, cleanliness, resource usage, and damage to the clothes duringthe cycle.
 12. The appliance development toolkit of claim 4 wherein thesecond instances relate to a content target.
 13. The appliancedevelopment toolkit of claim 12 wherein the content target is theappliance and the converter creates content for direct use by theappliance.
 14. The appliance development toolkit of claim 2 wherein themodel instance editor derives validation rules for the content from themodel.
 15. The appliance development toolkit of claim 2 wherein aportion of behavior of the model instance editor is derived from one ofthe appliance user domain data model and the source identificationdomain model.
 16. The appliance development toolkit of claim 2 whereinthe model is functionally equivalent to a UML class diagram.
 17. Theappliance development toolkit of claim 2 wherein the model isfunctionally equivalent to one of a database schema database and adatabase having a plurality of records.
 18. The appliance developmenttoolkit of claim 1 further comprising at least one viewer for viewingthe content.
 19. The appliance development toolkit of claim 1 whereinthe content is formatted as at least one of at least one relationaldatabase, XML document, CSV file, binary file, data collection, memorystructure, object structure, object graph, object tree, memory heap,machine code, source code, and text file.
 20. The appliance developmenttoolkit of claim 1 wherein the content is configured by the converterfor a predetermined content target to use the content with the appliancewhen the content target is in communication with the appliance.
 21. Theappliance development toolkit of claim 20 wherein the content target isone of a remote client, a local client, and an internal client of theappliance.
 22. The appliance development toolkit of claim 20 wherein thecontent target is one of the appliance, an appliance accessory and aconsumable information holder.
 23. The appliance development toolkit ofclaim 20 wherein communication between the content target and theappliance is one of continuous and momentary.
 24. The appliancedevelopment toolkit of claim 1 wherein the content affects the cycle ofoperation of the appliance.
 25. The appliance development toolkit ofclaim 1 wherein the content affects a user interface of the appliance.26. The appliance development toolkit of claim 1 wherein the content isconfigured to be at least one of a cycle structure, a custom cycle, abranded cycle, user attached data about appliance control functionality,a fault tree, a diagnostic test, an appliance user interface, appliancenetwork communication, routing tables for appliance networkcommunication, stain treatment, cooking, cooking algorithms, cookingvessels, meal preparation, dish preparation, recipes, units conversion,ingredients, ingredient substitution, dietary needs, nutritionalconstraints, nutritional information, detergents, softeners, fragrances,clothing, stains, soils, appliance use and care, appliance FAQ,consumables meta data, meal participants, personal profiles, personalpreferences, inventory information, personal schedules, identificationof one of a person, article, other appliance, and a consumable, andinformation associated with consumables.
 27. The toolkit of claim 1further comprising an encoder for encoding content onto a consumableinformation holder.